0.0. Course
In one glance
- You will: Choose a route, understand its prerequisites, and identify the evidence needed to finish.
- You need: Nothing beyond a browser.
- Time: about 15 minutes, orientation.
Who is this course for?
This course is for Python developers building agents and platform engineers operating them.
You should already write functions, import modules, create a venv, install packages with pip, and read a traceback. The course introduces agent-specific concepts, not Python programming. Prepare with the Python tutorial and its virtual environments chapter.
For Part II, you should already understand container images, Deployments, Services, Secrets, volumes, namespaces, and kubectl. Prepare with Kubernetes Basics and the Docker workshop. The course teaches how those facilities support agents rather than reteaching Kubernetes.
What does Part I teach?
Part I builds an incident assistant on your laptop with Python and Google ADK.
Follow Setup, First Agent, and the cumulative Workshop. Consult Chapters 2–4 as each exercise introduces tools, sessions, approvals, workflows, and quality. Install MLflow when you have evaluation results to inspect.
The workshop copies your preceding step into a new directory, keeps completed work, and refuses to overwrite an existing exercise. Each step has a check, a prediction to test, and a separate solution. This is how you build understanding before navigating the full reference.
The developer completion contract is a working agent, tested tools, isolated state, approval enforcement, an evaluation dataset, and a documented API/A2A boundary. A green Python test suite alone is not evidence of useful live model behavior.
What changes in Part II?
Part II assumes Kubernetes knowledge and adds operational responsibility around the same application.
Chapters 5–7 teach agentgateway, kagent, local Kubernetes delivery, OpenTelemetry, Prometheus, Grafana, feedback, and recovery. This part needs Docker, more memory and disk, and comfort debugging distributed systems.
The platform controls model and MCP access, credentials, resources, health, rollout, and recovery. The agent continues to own its domain behavior and guarded write boundary. Platform learners may start from the tested reference instead of completing every workshop edit.
Gemini remains the main model path on local Kubernetes. Ollama is Plan B. GKE, Vertex AI, GCS, and cloud identity are an optional extension with separate cost and deployment decisions.
Why use ADK, agentgateway, kagent, and MLflow?
Each tool owns a distinct teaching problem.
| Tool | Reason to include it | First required use |
|---|---|---|
| ADK | Python agent runtime, local debugger, API, and A2A integration | First Agent |
| pytest | Deterministic regression checks for the completed application | Quality |
| MLflow | Trace inspection, evaluation comparisons, and evidence artifacts | Evaluations |
| agentgateway | Shared access and policy for models, MCP, and A2A traffic | Gateway |
| kagent | Kubernetes agent resources and lifecycle integration | Platform |
| OpenTelemetry | Portable telemetry from application to platform | Tracing |
| Prometheus and Grafana | Service health, capacity, and alerts | Monitoring |
Start prompts in Git. The prompt registry, model judges, semantic retrieval, multi-agent delegation, cloud deployment, and OSS release administration are advanced options. Each must solve an observed problem before becoming part of your own project.
3.8. Framework Comparison compares ADK and LangGraph without maintaining a second course implementation. The AAIF material explains the role of shared standards and projects without assuming which tools will dominate later.
What is free and what is open source?
Course text is CC BY 4.0; repository software is MIT, with third-party licenses documented separately.
The agent and platform stack uses open-source software. The default Gemini service is proprietary and requires an account and API key. Free quotas are conditional and can change. See 1.4. Providers before a hosted call.
The optional Qwen3/Ollama path uses an Apache-2.0 open-weight model and local compute. Open weights do not imply that every training artifact is available. Offline fakes and recorded examples need neither hosted inference nor local model hardware.
How should you assess your progress?
Save evidence for what you actually ran.
| Outcome | Required exercise evidence |
|---|---|
| Build a Python agent | Complete the cumulative 2.6. Workshop checks and explain their failures |
| Evaluate a behavioral boundary | In 4.7. Evaluation Reference, add one adversarial case and its deterministic validator |
| Operate the application | Complete the gateway, deployment, observation, and recovery drills for the platform capstone |
- Exercise proof: predict a result, edit your code, run the offline check, and explain a failure.
- Developer proof: compare live answers against a small labeled dataset and record model, prompt, date, and configuration.
- Platform proof: deploy the tested application, trace a request, observe a failure, and demonstrate recovery.
- Capstone proof: change the domain while preserving the relevant safety and operating contracts.
Use the split rubric in 8.7. Capstone. Someone should be able to reproduce your result from your instructions; maintainers' tests do not replace learner trials.
What proves this page worked?
Write down which part you are taking and one capability you intend to demonstrate.
You are done when:
- You can satisfy the prerequisites or have chosen a preparation resource.
- You can explain the developer/platform handoff and the provider cost boundary.
- You know that worked solutions, offline checks, and live evaluations serve different purposes.
Continue to 1.0. System when you are ready to prepare the laptop environment.